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Objectives: This paper will present an overview of the developmental effort in harmonizing clinical knowledge modeling 
using the Detailed Clinical Models (DCMs), and will explain how it can contribute to the preservation of Electronic Health 
Records (EHR) data. Methods: Clinical knowledge modeling is vital for the management and preservation of EHR and data. 
Such modeling provides common data elements and terminology binding with the intention of capturing and managing 
clinical information over time and location independent from technology. Any EHR data exchange without an agreed clini- 
cal knowledge modeUng will potentially result in loss of information. Results: Many attempts exist from the past to model 
clinical knowledge for the benefits of semantic interoperability using standardized data representation and common termi- 
nologies. The objective of each project is similar with respect to consistent representation of clinical data, using standardized 
terminologies, and an overall logical approach. However, the conceptual, logical, and the technical expressions are quite dif- 
ferent in one clinical knowledge modeling approach versus another. There currently are synergies under the Clinical Infor- 
mation Modeling Initiative (CIMI) in order to create a harmonized reference model for chnical knowledge models. Conclu- 
sions: The goal for the CIMI is to create a reference model and formalisms based on for instance the DCM (ISO/TS 13972), 
among other work. A global repository of DCMs may potentially be established in the future. 
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I. Introduction 

For many healthcare professionals there is no greater con- 
trast between their main professional value of human cen- 
tered care for a person with an illness, and the digitized 
numbers crunched by computers. This contradiction is very 
fundamental because healthcare professionals' baseline 
values imply individualization of tailored care. In contrast, 
automation is still not beyond the stage where the Von 
Neumann principle requires any computer activity to be 
transformed into sets of binary values, manageable through 
the funnel of the computer processor, albeit nowadays in 
parallel. This contradiction materializes often in a perceived 
or real resistance of clinicians towards computer use in 
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healthcare in general, and Electronic Health Records (EHR) 
in particular. 

Authors consider two main developments that might lead 
to a change in the future. Healthcare professionals realize 
they cannot afford information processing by hand anymore, 
urging a systematic approach to information management. 
The challenge for healthcare can be summarized as "of- 
fer better quality of care with less money and decreasing 
numbers of professionals to a growing population of elderly 
people with increasing numbers of chronic diseases." The 
second development is that software can be realized in 
increasingly shorter development cycles, based on model 
driven approaches, user friendly interfaces, parallel process- 
ing, and other improvements in the world of information 
and communication technology. Their impact is that user 
requirements can be met much easier today than in the time 
each command had to be entered after the prompt. 

One particularly interesting novelty in this space is the 
development and deployment of so called Detailed CUnical 
Models or DCMs [1-3]. ISO/TS 13972 defines a DCM as "an 
information model designed to express one or more clinical 
concept(s) and their context in a standardized and reusable 
manner, specifying the requirements for clinical informa- 
tion as a discrete set of logical cUnical data elements [2]." So 
a model, hence reduction of reality, with clinical knowledge, 
so a focus on healthcare, and it specifies concepts and data 
elements, so meaning is put into computable environments. 
The purpose of this paper is to give further explanation 
about the goals, requirements, position and relevance of 
DCMs and how they can contribute to the long-term preser- 
vation of healthcare data. 

II. Methods 

1. Two Level Modeling 

In the early nineties, a group of smart scientists in the area 
of health informatics invented an approach to the develop- 
ment of EHRs which was called two level modeling [4]. In 
this approach, the generic functions of record systems, such 
as entering, storing, presenting, managing, communicat- 



Level 1 ■ 


DCM 


domain 1 


repository 




Level 2 1 


Entry and 


system H 


presentation 



Termonology 
and coding 



Medical 
knowledge 



store and 
process 



Communication 

J 

Figure 1. Two level modeling in Detailed Clinical Models (DCMs). 
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ing, and adding generic data, such as patient name and ID, 
location, time, professional (e.g., through the login), where 
separated out from the clinical details. And, these clinical 
details can be millions, and only need specific descriptions 
to distinguish these from each other. Figure 1 illustrates the 
distinction [5]. 

2. Different Approaches 

Following this approach several initiatives emerged in which 
the clinical knowledge was specified, so that computers 
can operate on this and generate meaningful information. 
These various approaches have been reviewed [3] . Different 
initiatives to create collections of clinical knowledge mod- 
els include the OpenEHR archetypes [6], Intermountain 
Healthcare clinical element models [1], the Netherlands care 
information models [7], and South Korea clinical contents 
models [8], among others. Following the original separation 
suggested by Rector et al. [4], these projects do lead to simi- 
lar descriptions of health-related data and in some instances 
their context. 

However, there are differences as well [3]. Some do not 
include the medical background knowledge, some do apply 
standardized terminologies and codes, others do not, or use 
internal code mechanisms. Also, differences exist in the logi- 
cal formats and technical representations applied. In particu- 
lar the following specification methods are used: Archetype 
Definition Language (ADL), Unified Modeling Language 
(UML) and/ or extensible Markup Language (XML). There 
is also differs in the use of a reference model or not. A refer- 
ence model imposes specific characteristics to the clinical 
models, to let these fit in a specific system or implementa- 
tion specification. Given the gap mentioned in the intro- 
duction, we also see efforts to create tools to communicate 
with professionals. Due to the quite significant differences, 
these models cannot be used from one project to the other. 
Partly this is because of the ever-existing cultural differences 
and realm specifics. However, if we move beyond that, we 
see ADL dialects (e.g., ISO 13606 versus OpenEHR based), 
UML variants (e.g., proper specifications from the Object 
Management Group versus the Health Level 7 [HL7] colorful 
dialect), and in the XML space, each project has their own 
tag names and build up. So, despite the common ground: i.e., 
the same medical knowledge, the same data elements, the 
same codes from standardized terminologies, these efforts 
do not deliver full semantically interoperable specifications, 
due to requiring the systems to adhere to specific reference 
models and computational formats. 
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3. Detailed Clinical Modelling 

Time for a change! With the DCM approach the benefits 
of the two level modeling are respected and the enormous 
efforts that went into the clinical modeling efforts are also 
acknowledged. The idea dates back to 2007 where during a 
workshop, an overarching approach called Detailed Clinical 
Modeling emerged, using a term from Huff et al. [1]. This 
approach takes the commonalties of the various specifica- 
tions to keep the conceptual descriptions and the logical 
models of data elements, code binding, relationships, data 
type specifications and such [9]. However, it does not go 
to the level of physical specification, and even, the logical 
model can easily be converted to reference model based ap- 
proaches as Health Level 7 Reference Information Model 
(HL7 RIM) or OpenEHR or reference models. 

Due to the interoperability issues among these clinical 
modeling approaches and the investments already made, 
there currently is an approach trying to harmonize the ex- 
isting work. This is carried out by the Clinical Information 
Modeling Initiative (CIMI). Their goal is to create a harmo- 
nized reference model for clinical knowledge models using 
both the ADL and UML formalisms. From these baseline 
formats, any kind of technical artifact can potentially be de- 
rived. CIMI also works on an EHR cUnical model repository 
as open content. However, in practice, with all good inten- 
tions, CIMI has created yet another reference model and yet 
another dialect of ADL. Nevertheless, other initiatives seem 
to start picking these harmonization results up. 

III. Results 

1. DCMs in MDA 

Modern development techniques apply often the Model 
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Figure 2. A three-dimensional architectural approach in Detailed 
Clinical Models (DCMs). 



Driven Architecture (MDA). In this, models are important, 
and reside at the logical level mostly. DCMs have a place in 
MDA. This can best be explained using the Generic Com- 
ponent Model (GCM) [10]. This cubical model positions 
DCMs in healthcare architectures, using a three-dimensional 
space. GCM characterizes any system by three axes: domain, 
system components, and system development (Figure 2). 

At the system axis (x-axis), the Reference Model of Open 
Distributed Processing (RM-ODP) serves as a coordinating 
framework. This framework comprises with five components 
namely the enterprise viewpoint, information viewpoint, 
computational viewpoint, engineering viewpoint, and finally 
technical viewpoint. The RM-ODP positions DCMs in the 
enterprise, information and the computation space (e.g., for 
detailed computational specifications, such as calculation of 
total scores on data and such). 

The second axis (y-axis) specifies the system development 
approach of the MDA. MDA separates the healthcare busi- 
ness and the application logic of EHRs from the specific 
implementation technology [11]. According to Blobel [10], 
this MDA depends on standards, traceability, and explicit 
relationships between system components. And at the lowest 
level of clinical detail, that is what DCMs provide: consisten- 
cy, traceability, and reusability, while covering the conceptual 
and logical levels. DCMs fit into larger logical models, such 
as reference (information) models. 

At the domain axis (z-axis), the different healthcare do- 
mains, such as clinical specialties, are depicted. It is repre- 
sented from the business at the top, to the fine grained data 
elements on the bottom. The latter specified in DCMs, reus- 
able from domain to domain. 

On the physical level, the DCMs based health data from 
EHRs must be storable and remain available for many years 
and in numerous technologies. Looking at applicable tech- 
nologies for data preservation is relevant for chnical model- 
ing exercises. 

File format conversion engines that are constrained to one 
data type and in-house software base are available [12]. For 
example, FileFormat.Info (http://www.fileformat.info) in- 
cludes file format conversion tools for images only based on 
Java Advanced Imaging libraries (javax.imageio.* and javax. 
media.jai.*). There exist a few file format conversion ser- 
vices that support only certain conversion types (e.g., http:// 
www.ps2pdf com 1 conversion type; http://media-convert. 
com about 20 multi-media formats; http://www.zamzarcom 
selected conversions of document, image, music, video, and 
couple of CAD formats). The main drawback of the existing 
conversion systems is that they are not extensible (limited by 
the availability of specific libraries). 
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In order to design an extensible file format conversion sys- 
tem based on utilizing third party soflrware several problems 
have to be addressed [12]. First, the problem of automated 
execution of the software, most GUI based, without having 
access to an application programming interface. AutoHotkey 
(http://www.autohotkey.com) scripting is a viable option 
for the Windows operating system and the current Poly- 
glot implementation is based on it. Second, the problem of 
distributed computational resources has been approached 
in the past by the Grid community, TeraGrid (https://www. 
xsede.org/tg-archives) and Globus Toolkit (http://toolkit. 
globus.org/toolkit/), for building computational grids, and 
the design of workflow middleware that would manage the 
execution, such as DAGMan, CCA (http://www.cca-forum. 
org) or Taverna (http://www.taverna.org.uk/), among others. 

Due to the heterogeneity of computational hardware, this 
problem also requires considerations about options for par- 
allel processing [12], for instance, the use of 1) a message 
passing interface is designed for the coordination of a pro- 
gram running as multiple processes in a distributed memory 
environment by using passing control messages; 2) open 
multi-processing is intended for shared memory machines. 
It uses a multithreading approach where the master threads 
fork any number of slave threads; 3) the map reduce parallel 
programming paradigm for commodity clusters which al- 
lows programmers write simple Map and Reduce functions, 
which are then automatically parallelized without requiring 
the programmers to code the details and communications of 
parallel processes; and 4) novel architectures FPGAs, GPUs, 
multiple CPUs. Unfortunately, none of the existing grid solu- 
tions are an option when utilizing 3rd party binaries com- 
piled for specific hardware on one machine. 

Workflow solutions could potentially orchestrate calling 
computational resources based on a conversion sequences, 
however most do not robustly deal with solely GUI based 
software and also tasks specific needs must be considered, 
such as clustering the conversion execution sequence into 
segments that do not require data movement, and then man- 
aging and monitoring entire conversion executions [12]. 

Such technologies would contribute to the preservation of 
data in EHRs and their use in various systems, using various 
technical formats and representations of the same clinical 
data based on DCMs. 

2. Requirements for Clinical Data 

Healthcare has several different purposes for use of clinical 
data, such as chnical care, continuity of care, quality indica- 
tors, decision support, management, billing information, 
clinical trials, and epidemiological studies among others [9]. 
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This is illustrated in Figure 3. Each purpose requires analysis 
of the requirements, in particular data granularity, validity, 
relevance, preciseness, and reliability. Each data use implies 
a specific set of attributes and constraints for the data entry, 
storage, processing, presentation, communication, selection, 
and aggregation. However, important is also that each data 
reuse from an EHR poses validity and reUability questions. 
For example, are there biases, confounders, and other fac- 
tors to be taken into account? And finally, each data use has 
its own expectations for data preservation. The assumption 
is that clinical data are recorded into an EHR system dur- 
ing the primary care process, and that DCMs are applied to 
guide the data entry. For each purpose the DCMs serve as 
the semantic baseline. For instance, for continuity of care, 
the DCMs will be transformed into a HL7 v3 XML format. 
Hence they serve to define the message or document pay- 
load. Here the DCMs prove their value. It might be that all 
data according to the DCM are stored in the EHR, but not 
all data need to be exchanged. At the message/document 
definition a selection of the data can be made. However, each 
data element exchanged will still have all of the standardized 
characteristics according the DCM. 

For all other purposes, similar mechanisms will apply. All 
data in EHR are available, process of selection might lead to 
minimizing the amount of data required. And then the ag- 
gregation process will add some features. For instance for 
a quaUty indicator, the denominator can be a data element 
standardized in a DCM, while the aggregation process re- 
quires a nominator as numeric value derived from the num- 
ber of occurrences of the denominator, e.g., 'pressure ulcer 
risk present' as denominator specified as resulting data from 
an risk assessment, and the occurrence of 80 in a patient 
population of 320 would reveal an incidence rate of 25%. 
The data element handled comes from the DCM. The cal- 
culations are then based on scientific methods for incidence 




Figure 3. Example of Detailed Clinical Models used for registra- 
tion and reporting. 
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rates, and some policy might determine that the percentage 
of patients at risk for pressure ulcer might be a good quality 
indicator. However, in actual care, this indicator might need 
a second standard, DCM based, data element to be present 
and handled similarly, e.g., "patient receives preventive mea- 
sures for pressure ulcer." If 80 of the 320 patients would get 
preventive care, this would be 25%, and a perfect match to 
the risk, and hence perfect care. For most goals, a selection 



Table 1. Summary of core content areas of Detailed Clinical 
Models (DCMs) according ISO/TS 13972 
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Detailed Clinical Models 

of data elements according DCMs will be used, but still keep 
its standard features. 

3. What Must Be Included in a Well-Designed DCM 

In ISO/TS 13972 the characteristics for DCMs are specified 
[2]. These have been summarized by Goossen [9] and are 
presented in Table 1 below. This implies that a proper DCM 
has a linkage to the medical knowledge about the concept 
that is modeled. And for each model, the data elements must 
be specified extensionaUy, with all core parts included. Fur- 
ther, lack of metadata, such as authorship, versioning and 
endorsement, is seen as a risk to patient safety, and should 
therefore be added to each DCM. Reader is referred to the 
TS for the complete listing of criteria for DCMs. 

4. Comparing Existing Formats 

Comparing existing formats for the same medical concepts 
reveals the residue that is the core clinical content specified 
in DCMs. Goossen and Goossen-Baremans [13] carried out 
an analysis of clinical concepts in the format of archetype, 
HL7 v3 model, and DCM in UML format. Although that 
approach is using a specific bottom up analysis, and looked 
at data types and code bindings, it also showed the overall 
models. In this paper, we present a similar analysis on logical 
model level of the Glasgow Coma Scale (GCS) [14] . The GCS 
is used to determine the level of consciousness of patients 
after trauma, with stroke, or for other head injuries [14]. 
The GCS consists of three categories of data, representing 



Table 2. Concept level: example Glasgow Coma Scale (GCS) 



The GCS is used to measure the level of consciousness of a patient with respect to verbal, motor and eye 
movement reactions. It has a total score summated from the three underlying observations. 

Node representation does allow identifying each of the three observations as a single data item and one 
for the total score. The total score derivation is defined. Each node can be linked to an external code 
system, e.g., LOINC 9269-2 for Glasgow Score Total. 

R-MIM Observation Class representation for each of the individual score items and component rela- 
tionships to identify hierarchical relationship with total score. Total score as separate instance of Ob- 
servation Class. Each class represented for instance by a LOINC and/or SNOMED CT code: LOINC 
9269-2 Glasgow Score Total, SNOMED CT 281395000: GCS eye opening sub-score. 

Each data element is described as a separate UML class in the diagram. The relationship between data 
elements (classes) can be expressed. The derivation into the total score is expressed and class models 
can be drawn, including defining the hierarchical relationships. The classes can link to coding sys- 
tems again, such as LOINC 9269-2 Glasgow Score Total, and SNOMED CT 281395000 for the GCS 
eye opening sub-score. This is currently done through tagged values. In the future OMG specification 
wOl be used for this. 



Clinical knowledge 
OpenEHR archetype 

HL7 v3 message using 
DCM 



EHR: Electronic Health Record, LOINC: Logical Observation Identifiers Names and Codes, HL7: Health Level Seven, SNOMED 
CT: Systematized Nomenclature of Medicine Clinical Terms, DCM: Detailed Clinical Models, OMG: Object Management Group. 
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archetype (adLversion=1 .4) openEHR-EHR-OBSERVATION.glasgow_coma.v1 


concept [atOOOO] - Glasgow Coma Scale 




language original_language = <[ISO_639-1::en]> 


»» Snip 8<8<8<8< 




purpose = <"Used to collect clinical observations regarding the level of consciousness"> 


»» Snip 8<8<8<8< 




definition 




OBSERVATION[atOOOO] matches { 


- Glasgow Coma Scale 


data matches { HISTORY[at0001] matches »» Snip 8<8<8<8< 


data matches {ITEM_TREE[at0003] matches »» Snip 8<8<8<8< 


ELEMENT[at0009] occurrences 


matches {0..1} matches - Best eye response 


value matches { 




1|[local::at0010], 


- No eye opening 


2|[local::at0011], 


- Eye opening in response to pain 


3|[local::at0012], 


- Eye opening to speech 


4|[local:;at0013] 


- Eyes opening spontaneously} 


ELEMENT[at0007] occurrences 


matches {0..1} matches - Best verbal response 


value matches { 




1|[local::at0014], 


- None 


2|[local::at0015], 


- Incomprehensible sounds 


3|[local::at0016], 


- Inappropriate words 


4|[local::at0017], 


- Confused 


5|[local::at0018] 


- Oriented} 


ELEMENT[at0008] occurrences 


matches {0..1} matches - Best motor response 


value matches { 




1|[lccal::at0019], 


- No motor response 


2|[local::at0020], 


- Abnormal extension to pain 


3|[local::at0021], 


- Abnormal flexion to pain 


4|[local::at0022], 


- Flexion withdrawal from pain 


5|[local::at0023], 


- Localizes to pain 


6|[local::at0024] 


- Obeys commands} 


ELEMENT[at0026] occurrences matches {0..1} matches {- Score 


value matches {DV_COUNT matches {magnitude matches {|>=0|} } } 


ontology 





Figure 4. Glasgow Coma Scale arche- 
type fragment. 



Glasgow Coma Scale 

< (NICTZ_2004_GGSrev0.94June05}) 

Glascow Coma Scale v.0.3 Eng 



Choice 



Glasgow_Coma_Scale_Total 

classCode*: <= OSS 
moodCode*: <= EVN 

code: CD CWE [..] 

LogicalObservationldentifierNamesAndCodes 
"LOINC 9269-2" 

derivationExpr: ST [0..1] "sumscore" 
effectiveTime: GTS [0..1] 
value: INT[0..1] 

InterprstatlonCods: SET<CE> CWE [0..*] 
<= Observationlnterprelation "score <=8 
severe brain injury; score between 9 and 12: 
moderate brain injury; score between 13 and 
15: mild brain injury." 
MethodCode: SET<CE> CWE [0..*] 
<= ObservationMethod 
"LEGIT+PARAL+TUBE+PARTUB" 



EMV_score_total 

ClassCode*: <= OSS 
moodCode*; <= EVN 

code; CD CWE [1..1] 



LogicalObservationldentifierNamesAndCodes 
"LOINC 9269-2" 

derivationExpr: ST [0..1] "Sumscore" 
effectiveTime; TS [0..1] 
value: STT[0..1] 

interpretationCode: SET<CE> CWE [0..*] 
<= Observationlnterpretation 
(E-r;l-V 4-6-5-normal; 1-5-2-coma) 



1..1 gCSEyeOpening 



componentl 
typeCode*: <=COMP 



GCS_EyeOpening 

ClassCode*: <= OSS 
moodCode*: <= EVN 

code*: CD CWE [1..1] 

<= LogicalObservationldentifierNamesAndCodes "9267-6' 

effecliveTlme: TS [0..1] 

value": CS CWE [1..1]<= GCS_E 

methodCode; SET<CE> CWE [0..*] <= ObservationMethod 
(4=spontaneous, 3=to speech, 2=to pain, 1=none, C= 
not to determine) 



1..1 gCSMotor 



component2 
typeCode*: <=COMP 



GCS_Motor 

ClassCode*: <= OBS 
moodCode*: <= EVN 
code: CD CWE [0..1] 

LogicalObservationldentifierNamesAndCodes "9268-4" 
effectiveTime: TS [0..1] 
value*: CS CWE [1..1]<= GCS-M (fz) 
methodCode: SET<CE> CWE [0..*] <= ObservationMethod 
(6=To verbal command: obeys, 5=To painful stimulus: 
localizes pain, 4=Flexion-withdrawal, 3-Flexion-abnormal, 
2-ExtensiDn, 1-No response, P-paralysis.) 



1..1 gCS_Verbal 



components 
typeCode*: <=COMP 



GCS_Verbal 

ClassCode*: <= OSS 
moodCode*: <= EVN 

code: CD CWE [0..1] 
<= LogicalObseivationldentifierNamesAndCodes "9270-0" 
effectiveTime; TS [0..1] 
value*; CS CWE [1..1]<= CGS-V 

mettiodCode: SET<CE> CWE [0..*] <= Obsen/ationMethod 
(5=0riented and converses, 4=Disoriented and converses, 
3=lnappropriate words, 2=lncomprehensible sounds, 1 = 
No response, T=Tube/Tracheotomy) 



Figure 5. Glasgow Coma Scale rep- 
resented In Health Level 7 
version 3 Reference Infor- 
mation Model classes. 
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<!- Total score on Glasgow Coma Scale-> 

<pertinentlnformation3 typeCode="PERT" contextConductionlnd="true"> 
<!- GCS total score -> 

<observation moodCode="EVN"> 
<code code="35088-4" codeSystem="2. 16.840.1 .1 13883.1 1 .164927> 
<value xsi:type="CO" value="8"/> 
</observation> 
<!- Glasgow Coma Scale Eye opening-> 
<observation moodCode="E\/N"> 
<code code="9267-6" codeSystem="2. 16. 840.1. 113883.6. 1"/> 
<value xsi:type="CO" value="3" /> 
</observation> 
<!- Glasgow Coma Scale Motor-> 
<observation moodCode="E\/N"> 
<code code="9268-4 " codeSystem="2.16.840.1 .1 1 3883.6. 17> 
<value xsi:type="CO" value="3" /> 
</observation> 
<!- Glasgow Coma Scale Verbal -> 
<observation moodCode="EVN"> 

<code code="9270-0" codeSystem="2. 16. 840.1. 113883.6. 17> 
<value xsi:type="CO" value="27> 
</observation> 
</pertinentlnformation3> 
</pertinentlnformation3> 



Figure 6. Glasgow Coma Scale in 
Health Level 7 version 3 
extensible Markup Lan- 
guage (XML) formalism 
(derived from the classes 
in Figure 5). 
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Name: Information Model 

Auttior: Michael van derZel 

Version 0.75 

Created: 1/8/2010 13:51:46 

Updated: 1/29/2014 16:40:42 
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{if Eye opening not ^ 
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then document 0} 



sr 

InfluencingFactors 



«container» 
EC-choice 



ST 






« state 
C 


0..1 






0..1 












CO 


•Kdata, enumerations) 
E=Best Eye opening 




«enum3> 






+ No response: CO=1 

+ Opens the eyes after a painful stimulus :C0=2 
+ Opens the eyes after a verbal stimulus :C0=3 
+ Spontaneous :C0=2 



«rootconcept» 
GlasgowComa Scale 



«data, derivati.. 
Total Score 



ST 



<; state » 
P 



«data, enumerations 
M=Best Motor response 



«enums> 

+ Extension: C0=2 

+ Flexion-abnormal :C0=3 

+ Flexion-withdrawal :C0=4 

+ No response :C0=1 

+ Obeys verbal commands :C0=6 

+ To painful stimulus: localizes pain :C0=5 




Inv: self.value=sum 
(Items) 





Inv: self.value >=3 and 
self. value <=15 



«container» 
VT-choice 



ts, 

{if Tube or Tracheotomy 
then document T} 



•Xdata, enumerations 
V=Best Verbal reaction 



«enums 

+ Disoriented and converses :C0=4 

+ Inappropriate words :C0-3 

+ Incomprehensible sounds :C0=2 

+ No response :C0=1 

+ Oriented and converses :C0=5 



Figure 7. Detailed Clinical Models (DCMs) in Unified Modeling Language of the Glasgow Coma Scale (2014 revised but unpublished 
version). 
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eye opening, best motor response and best verbal response 
that are summed up into a total score. The GCS is scored by 
documenting the number representing the best response for 
each category that could be observed with the patient. Table 
2 specifies the conceptual knowledge about the GCS. 

The different expressions of the GCS in the different model- 
ing approaches are illustrated below. For the ADL and XML, 
the basic parts showing the semantics are presented. Many 
technical ADL and XML specifications have been left out for 
easy reading. First the GCS core as an archetype version will 
be depicted (Figure 4). 

Next, the HL7 v3 RIM based artifact is shown (Figure 5), 
and its XML equivalent (Figure 6). 

Finally, the UML representation of a DCM is shown (Figure 
7) and a preliminary representation using the recent HL7 
Fast Healthcare Interoperability Resources (FHIR) approach 
(Figure 8). Note that a DCM can be expressed in any logi- 
cal modeUng method. UML is just for the illustration of the 
commonalties and differences. An example DCM is repre- 
sented in Figure 7, using UML. 

Finally, HL7 is currently investing in the new format for 
data exchange, FHIR [15]. The power to preserve invest- 
ments in DCMs is illustrated best that in a very short time 
the FHIR resource exporter could be added to the used 
modeling tool, and export of FHIR resource format is avail- 



Figure 8. Glasgow Coma Scale fragments presented in Fast 
Healthcare Interoperability Resources extensible 
Markup Language (XML). 
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able. Figure 8 illustrates a fragment of the FHIR resource, 
showing the four core data elements of the GCS. Note that 
to keep this readable, the XML parts that define the GCS 
and its values in FHIR have been left out of the example, and 
none core parts have also been removed. FHIR allows both 
the Systematized Nomenclature of Medicine Clinical Terms 
(SNOMED CT) coding [16] and the Logical Observation 
Identifiers Names and Codes (LOINC) coding [17] to be 
present in the definition. Again, we only show here LOINC 
codes as example. 

What these examples illustrate clearly is that the medical 
knowledge is the same; each model has the core compo- 
nents of the GCS expressed. And that must be so to ensure 
semantic interoperabihty. However, due to the technological 
choices, it is obvious that the technical specification part for 
each implementation specification differs. The art of mod- 
eling requires that we try every attempt to move from the 
technological approach to the clinician, and this can be done 
through the logical modeling of the conceptual content. In 
other words, let the technicians and modelers deal with the 
intricacies of modeling, do not bother doctors and nurses 
with it. But offer tooling that allow to do this consistently 
so that every implementation format for the computational 
level can use it adequately. 

These results indicate that it is feasible to compare and 
reuse information models for single or combined clinical 
data elements and for assessment scales from one imple- 
mentation approach to the other [13,18]. When the specific 
limitations of each approach are taken into account and a 
precise analysis of each data-item is carried out, it is possible 
to reveal the semantics of the different models, abstract from 
that and transform it into another logical model. In par- 
ticular, the HL7 template approach and the ISO/CEN 13606 
and OpenEHR archetypes reveal more commonalties than 
differences. Semantics are about the interaction between the 
medical knowledge represented in the clinical concepts, the 
information model representing it in technology, and the 
terminology model revealing its semantics [13]. The present- 
ed models do have a generic and equivalent structure where 
these concepts fit. The structures include for HL7 v3 the 
Clinical Statement Pattern, and for the 13606 and OpenEHR 
archetypes the Entry level. Both structures allow 1 — n data 
elements to be represented and linked together. The DCM 
example in UML applies a full class diagram in which the 
concept is modeled; each data element is represented in a 
class. According to Goossen and Goossen-Baremans [13], 
the best level of comparing HL7 v3 and OpenEHR is at the 
Clinical Statement Pattern versus Entry level, respectively, 
where both express a single clinical relevant data element. 



<?xnnl version="1 .0" encoding="utf-8"?> 
<ValueSet xmlns:xsi="http://www.w3. org/2001 /XMLSohema- 
instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns="http://hl7.org/fhir"> 
<identifier/> 

<name value="GlasgowComaScaleConcepts7> 
<define/> 
<expansion> 
<contains> 

<system value="urn:oid:2.16.840.1.113883.6.1"/> 

<code value="9269-27> 

<display value-'Glasgow Score Total"/> 
</contains> 
<contains> 

<system value="urn:oid :2. 1 6.840. 1 . 1 1 3883,6.1 7> 

<code value="9268-47> 

<display value-'Glasgow Score Motor7> 
</contains> 
<contains> 

<system value="urn:oid:2. 1 6.840. 1 . 1 1 3883.6.1 7> 
<code value="9267-6"/> 

<display value-'Glasgow Score Eye Opening7> 

</contains> 
<oontains> 

<system value="urn:oid:2.16.840.1.113883.6.1"/> 
<code value="9270-0"/> 
<display value-'Glasgow Score Verbal"/> 
</contains> 
</expansion> 
</\/alueSet> 
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However, concepts do partly get their meaning from the 
structure they are embedded in. Hence this bottom up ap- 
proach will lead to 100% basic semantics equivalence for 
data elements, but it will never lead to a 100% comparability 
of the much more abstract reference models. 

However, it is possible to extract data from storage in one 
formalism and represent it into another formalism. And for 
the preservation of data that is very important. 

IV. Discussion 

The proper understanding of data in healthcare, and their 
proper representation which is necessary to bridge the gap 
between human centered caring for individuals and the zero 
and one conversion of computer processing of data, does 
require that the two level modeling is optimal. In this ap- 
proach, basis system functions and clinical content specifica- 
tion are separated. The clinical models fit in different health- 
care architectures and approaches, but are in each approach 
on the maximum (some say optimal) level of granularity. 

This MDA, with its different axis as illustrated with the 
GCM can be done through several examples of clinical mod- 
el specification that have in common the representation of 
knowledge, data, and semantics, but differ due to technologi- 
cal choices. The illustration of the GCS reveals that the core 
medical content is kept in the logical part of each modeling 
approach, facilitating reuse from one format to the other 
and allowing interoperability become true in some not to far 
away near future. For the preservation of clinical data this 
is important. Because besides the technical storage mecha- 
nisms, also the computational formalisms might cause dif- 
ficulties on the long run. This paper covered the conceptual 
example of one scale, the GCS, and its logical representation 
in various formats. Fragments of the computational specifi- 
cations have been presented, albeit incomplete. One impor- 
tant step which must be dealt with for each implementation 
technical specification is to test for the model and syntax 
correctness. For instance through XML schema and similar 
validations, or for the content through XML schematron. 

The ISO/TS 13972 on DCM specifies the key characteristics 
of properly modeled clinical content, and its appUcation to 
modeling will facilitate the reuse of models that are created 
elsewhere using a different approach. The work of CIMI is 
currently undertaking a first international effort to share 
each others models, once they have been abstracted and 
specified in a formalism that all can apply. This approach will 
contribute to the preservation of clinical data over time, lo- 
cation, and for various purposes, provided that the technical 
implementations will still be adequately tested. 
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